From CPOA : les premiers patrons

Introduction

Ce cours porte sur la Conception et Programmation Objet Avancée.

Concepts objets

Vous avez appris (cf. M2103 et M2104) un certain nombre de concepts objets :

• Abstraction
• Encapsulation
• Héritage
• Polymorphisme

Abstraction

Définition :

Abstraction

Définition (restrictive) :

Une classe est une abstraction des caractéristiques communes d’un ensemble d’objets.

Encapsulation

Définition :

Encapsulation

Définition (restrictive) :

Dans la description d’un objet, le but de l'encapsulation est de masquer les attributs et les méthodes, c’est-à-dire, la manière dont est réalisé le comportement de l’objet.

Héritage

Définition :

Héritage

Définition (simpliste) :

L’héritage est la transmission de caractéristiques à ses descendants.

La classe qui hérite dispose des méthodes et attributs de niveau public et protected de sa classe mère.

Polymorphisme

Le nom de polymorphisme vient du grec :

Polymorphisme

Le nom de polymorphisme vient du grec :

qui peut prendre plusieurs formes

Polymorphisme (suite)

On distingue généralement trois types de polymorphisme :

• Le polymorphisme ad hoc (également surcharge ou en anglais overloading)
• Le polymorphisme paramétrique (également généricité ou en anglais template)
• Le polymorphisme d’héritage (également redéfinition, spécialisation ou en anglais overriding)

Polymorphisme ad hoc

• Appelé aussi surcharge.
• Permet d’avoir des fonctions de même nom dans des classes sans aucun rapport entre elles.
• Permet de définir des opérateurs d’utilisation différente en fonction des paramètres.

int method(int,int);
int method(int);
int method(float,float);

Le polymorphisme paramétrique

Appelé aussi généricité.

interface Iterator<E> {
    boolean hasNext();
    E next();
}

public <T> static void copy(Collection<? extends T> source, Collection<? super T> dest) {
    for (T t : source) {
         dest.add(t);
    }
}

Le polymorphisme d’héritage

• Appelé aussi spécialisation (ou redéfinition).
• Lié à la redéfinition des méthodes héritées.

Objectifs de la conception objet

On essaye d’éviter trois problèmes principaux du développement :

La rigidité

Anticiper les évolutions susceptibles d’impacter l’application.

La fragilité

Eviter les erreurs provoquées par la modification d’une partie du code.

L’immobilité

Rendre moins difficile l’extraction d’une partie du code.

Bonnes pratiques et patrons

Pour répondre aux problèmes ci-dessus, on va s’attaquer à diminuer les dépendances et éviter l'"effet spaghetti".

Les qualités recherchées sont :

• Robustesse : les changements n’introduisent pas de régressions.
• Extensibilité : il est facile d’ajouter de nouvelles fonctionnalités.
• Réutilisabilité : il est possible de réutiliser certaines parties de code pour construire d’autres applications.

Bonnes pratiques et patrons (suite)

Nous allons apprendre des bonnes pratiques :

• Identifier les aspects qui varient et les séparer des aspects constants
• Programmer une interface, non une implémentation
• Préférer la composition à l’héritage
• Les classes doivent être ouvertes à l’extension, mais fermées à la modification
• Dépendez d’abstractions. Ne dépendez pas de classes concrètes (inversion des dépendances)
• Ne parlez pas aux inconnus

Bonnes pratiques et patrons (suite)

L’étape suivante consiste à apprendre les bonnes solutions de conception, ce qu’on appelle les patrons de conception (ou design patterns en anglais).

Organisation du cours

• La première semaine est consacrée aux principes généraux des patrons de conception, en partant d’un exemple (cours en fin de semaine).
• Les 5 ou 6 suivantes sont consacrées à l’étude de certains patrons classiques. Mise en pratique sur des exercices en TP.

  Le cours est inversé par rapport aux habitudes : Conception et étude d’un ou plusieurs patrons semaine N; mise en oeuvre en TP semaine N+1; puis cours en amphi (détails, discussions) en semaine N+2.

• Les 2 ou 3 dernières semaines, les étudiants sont en mode projet pour faire du refactoring d’applications réelles (conception aidée en TD sur les modèles UML™, mise en oeuvre en TP).

Organisation (suite)

Voici une proposition de déroulement des semaines :

Semaine 1

SuperCanard, le grand classique, [strategy]

Semaine 2

• [Singleton]

Semaine 3

Patrons [Fabrique], [Proxy], [Etat]

Semaine 4

• [Observateur]
  • version intuitive (2 interfaces)
  • version Java (classe Observable)

Semaine 5

L’exemple de Meyer : menus en objet

Semaine 6

• Patrons Décorateur, Façade, Visiteur
• MVC avec l’exemple JTable de Java
• Patrons Chaîne de responsabilité (juste en cours)

Semaines 7 et 8

• Quelques idées de projet final :
  • Refactorer un code généré par Umple.
  • Refactorer le code de MPA (mais pas le leur, celui d’un autre groupe)

Evaluation et notation

Comme prévu par le planning des contrôles, les étudiants auront :

• une note de projet (TPs + projet final) ⇒ coef. 1
• une note d’examen final (semaine 5) ⇒ coef. 2

Rappels sur des éléments Java importants

Importance du typage

Différents types de typage

Le fait d’attribuer un type (une classe) à une variable (un objet) peut se faire de plusieurs façons :

• statique
• dynamique
• duck typing

Typage statique

On parle de typage statique quand la majorité des vérifications de type sont effectuées au moment de la compilation.

int i = 0;  // cette déclaration indique explicitement que
            // la variable i est de type entier

Typage dynamique

Le typage dynamique consiste à laisser l’ordinateur réaliser l’opération de typage à la volée, lors de l’exécution du code.

Typage dynamique (exemple)

/**
 * @author André Peninou
 */
public class Type {
  void m() {
    System.out.println ("Type");
    }
}
public class SousType extends Type {
  void m() {
    System.out.println ("SousType");
  }
  void autreM(){
    System.out.println ("Spécifique SousType");
  }
}
...
    Type a = new Type();
    a.m(); // "Type"

    a = new SousType();
    a.m(); // "SousType"
    // Statique : a est un Type (à la compil)
    // Dynamique : a est un SousType au runtime.

    // D'où :
    a = new SousType();
    a.autreM();
    // NOK car type statique == A => autreM() n'existe pas à la compilation
...

Duck typing

Style de typage dynamique où la sémantique d’un objet (c’est-à-dire son type) est déterminée par l’ensemble de ses méthodes et de ses attributs, et non par un type défini et nommé explicitement par le programmeur.

Duck typing (exemple)

def calcule(a, b, c)
  return a*b+c
end

$a = calcule(6, 3, 2)
$b = calcule('6', 3, ', the number of the beast')

puts $a.to_s
puts $b.to_s

Ce qui donne :

20
666, the number of the beast

Importance de la visibilité

Dès que l’on commence à avoir une application conséquente, l’organisation en package devient obligatoire. Revenons donc sur les questions de visibilité des propriétés et méthodes, qui seront importants dans la plupart des aspects de ce module.

Si un champ d’une classe A :

• est private, il est accessible uniquement depuis sa propre classe ;
• a la visibilité package (visibilité par défaut, pas de mot-clef), il est accessible de partout dans le paquetage de A mais de nulle part ailleurs ;
• est protected, il est accessible de partout dans le paquetage de A et, si A est publique, grosso modo dans les classes héritant de A dans d’autres paquetages ;
• est public, il est accessible de partout dans le paquetage de A et, si A est publique, de partout ailleurs.

Importance de la visibilité (exemple)

package UN;
public class A {
  protected String attrprotected;
  String attrfriend; // friend
}

Si on définit une deuxième classe dans le même package :

package UN;
  class B {
    ...
    {
        A a = new A ();
        a.attrprotected// OK : même si bizarre
        a.attrfriend  // OK : visible package
    }
  }

package UN;
  class C extends A {
    ...
    {
        this.attrprotected// OK : normal
        this.attrfriend // OK : visible package
    }
  }

Importance de la visibilité (suite de l’exemple)

package DEUX;
  class B {
      ...
    {
        A a = new A ();
        a.attrprotected// NON OK : normal
        a.attrfriend  // NON OK : normal, proche de "private"
    }
  }

  class C extends A {
      ...
    {
        this.attrprotected// OK : normal car protected et héritage
        this.attrfriend // NON OK : normal, proche de "private"
    }
  }

Alors private ou protected ?

À la question private ou protected ? Quel est le mieux pour les attributs ?

• C’est une question de style de programmation !
• Puristes (cf. [Meyer]) ⇒ private
• Parfois utile : cf. Strategy, évite les getters/setters

Visibilité et UML

Retour sur les Membres static

class VariableDemo
{
  static int count=0;
  public void increment()
  {
    count++;
  }
  public static void main(String args[])
  {
    VariableDemo obj1=new VariableDemo();
    VariableDemo obj2=new VariableDemo();
    obj1.increment();
    obj2.increment();
    System.out.println("Obj1: count is="+obj1.count);
    System.out.println("Obj2: count is="+obj2.count);
  }
}

Output:

Obj1: count is=2
Obj2: count is=2

Membres static (suite)

Comment ça marche :

• Les variables static sont initialisées au chargement de la classe.
• Les variables static d’une classe sont initialisées avant que la moindre instance ne soit créée.
• Les variables static sont initialisées avant que la moindre méthode static ne s’exécute.

Méthodes static

import java.lang.Math;

class Another {
  public static void main(String[] args) {
    int result;

    result = Math.min(10, 20); //calling static method min by writing class name

    System.out.println(result);
    System.out.println(Math.max(100, 200));
  }
}

Méthodes static et appel aux méthodes non-statiques

public class Main {
    public static void main(String[] args) {
        Main p = new Main();
        k();
    }

    protected Main() {
        System.out.print("1234");
    }

    protected void k() {
    }
}

À l’exécution :

Main p = new Main();  // => prints 1234
k()                   // => raises error

Méthodes static et appel aux méthodes non-statiques (suite)

Static method cannot call non-static methods

Bien sûr que si, sauf qu’il faut que cette dernière porte sur une instance de la classe.

Méthodes static et appel aux méthodes non-statiques (suite)

Constructors are kind of a method with no return type.

En fait il vaudrait mieux les considérer comme une sorte de méthode statique. En effet elle ne requièrent pas de porter sur un objet!

Utilité générale des enum

Modélisation

Le type enumération est souvent utilisé en modélisation :

Propriétés

public enum Civilite {
  MADAME, MONSIEUR
}

• Chaque élément d’une énumération est un objet à part entière
• Les objets enum héritent de java.lang.Enum
• On peut compléter les comportements des objets en ajoutant des méthodes

Méthodes de base

• toString()

  System.out.println(Civilite.MADAME); //MADAME

• valueOf()

  Civilite civilite = Civilite.valueOf("MONSIEUR") ;

• values()

  Civilite[] civilites = Civilite.values() ;

• ordinal()

  Civilite civilite = Civilite.MONSIEUR ;
  System.out.println("Civilite : " + civilite + " [" + civilite.ordinal() + "]") ;
  // Civilite : MONSIEUR [1]

  Le 1er numéro d’ordre est 0.

• compareTo()

  System.out.println(Civilite.MADAME.compareTo(Civilite.MONSIEUR)) ;
  // -1

Exemple plus complexe

public enum Langage {
  //Objets directement construits
  JAVA("Langage JAVA", "Eclipse"),
  C ("Lanage C", "Code Block"),
  CPlus ("Langage C++", "Visual studio"),
  PHP ("Langage PHP", "PS Pad");

  private String name = "";
  private String editor = "";

  //Constructeur
  Langage(String name, String editor){
    this.name = name;
    this.editor = editor;
  }

  public void getEditor(){
    System.out.println("Editeur : " + editor);
  }

  public String toString(){
    return name;
  }

  public static void main(String args[]){
    Langage l1 = Langage.JAVA;
    Langage l2 = Langage.PHP;

    l1.getEditor();
    l2.getEditor();
  }
}

Questions?

Time for a quizz!